MANAGEMENT AND CONTROL OF CALL CENTER AND OFFICE 

TELEPHONY ASSETS 



Inventor: 
Edward L. Reuss 

Cross reference to Related Applications 
[0001] The subject matter of this application is related to co-pending U.S. 
Application No. 09/401,070, entitled "Accessory Interface Bus for Telephone Headset 
Adapter," by Arthur Anderson et al., filed September 22, 1999, [hereinafter, "Accessory 
Interface Bus"] the disclosure of which is herein incorporated in its entirety by reference. 

Background of the Invention 

Field of the Invention 

[0002] The present invention relates generally to the management and control of call 
center and office telephony assets, and in particular to managing and controlling those 
assets using the Internet Protocol or other networlc addressing. 

Background 

[0003] A typical call center operates in a large room with many desks equipped with 
telephones. Each desk and telephone is referred to as a station and is used by a customer 
service agent or representative. Incoming calls are queued, if necessary, and routed to an 
available agent by a central switching system called an Automatic Call Distributor 
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(ACD). Most of the telephones have headsets attached for the agent's comfort during 
long periods of telephone use. Each agent may have his or her own headset, or, less 
typically, the agents may share headsets. In a 24-hour call center, three or more agents 
may use a single station, each agent working a different shift. 
[0004] In non-ACD appUcations, where employees may have other responsibilities 
(e.g., technical support offices), the telephones may include various attachments. These 
attachments include a handset lifter to reduce answering the telephone to a single button 
push, and a flashing On-Line Indicator (OLI) to let others know when the user is 
engaged in a telephone conversation. Typically, each station is equipped with either a 
desktop computer or a computer terminal connected to a central computer. The call 
center may contain from a few stations to many hundreds of stations. Moreover, some 
large corporations have several call centers located in different locations around the 
world. 

[0005] One problem facing many call centers is asset management of the equipment 
for each station. The call center manager or technician must track where all of the 
equipment is located, test it for proper operation of the equipment, and perform 
diagnostics to identify the nature of any equipment failure. Presently, this task is 
performed manually by physically inspecting every piece of equipment in every call 
center station. 
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Summary of the Invention 
[0006] To enable the management and control of call center and office telephony 
assets, the assets are coupled to a central management system over a network. This 
ability to send and receive communications over a network enables a call center operator 
or office administrator to manage and control the assets from the central management 
system. Coupled to the network, the assets can be communicated with individually or as 
a group, directly or via a proxy. Accordingly, the operator or administrator has a high 
level of flexibility to manage and control the assets from any enabled location on the 
network. In addition, the network capability allows remote access to the assets as well as 
simultaneous access to assets at geographically distant locations, allowing easy 
management and control of a large inventory of call center assets. 
[0007] In one embodiment, a number of call center assets are coupled via a network 
to a central management computer. A network interface enables each call center asset to 
communicate with a central management computer. Li one embodiment, the call center 
assets include a globally unique electronic serial number, or some inteUigence for 
mapping to a globally unique serial number, which the assets use to identify themselves 
on the network, hi one embodiment, the electronic serial number is the same as or 
derived from each asset's Media Access Control (MAC) address. The call center assets 
communicate over the network using the Internet protocol (IP), their IP addresses 
derived using the MAC address of each asset or of a device associated with the asset. 
Once each call center asset is assigned a globally unique network address, the 
management and control system can selectively communicate with any call center asset 
coupled to the network. 
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[0008] In another embodiment, some or all of the assets communicate over the 
network using a proxy device. The proxy device includes a network interface for 
assigning a network address to its associated call center asset. A device may serve as a 
proxy for multiple call center assets. This allows assets that do not have a MAC address 
themselves to be identified on the network for asset management and control. 
[0009] The physical layer interface for connecting the call center assets to the 
network can be implemented in a variety of ways, depending on the application. In one 
embodiment, the assets are connected using Ethemet, with most assets having full 
Ethernet connectivity. In other embodiments, the assets are connected to a call center 
station computer using either a standard or proprietary local bus, or a combination 
thereof, and the station computer acts as an Ethemet proxy for the assets. In another 
embodiment, the signals between the network and the assets are modulated onto a 
telephone signal, which advantageously does not require a station computer. The assets 
may also communicate with the network via an Ethernet-enabled telephone using voice- 
over-IP (V oIP), wherein the telephone, a headset adapter, or another device acts as a 
gateway to the network. These and various other combinations can be used to 
implement connectivity among the call center assets and the central management 
computer, the specific design implementations driven by the particular system goals. 
[0010] Using the central management computer, an operator can perform several 
management functions on one or more call center assets coupled to the network. These 
include tracking the utilization of each asset and locating each asset on the network, 
which may be used to determine the asset's physical location at an enterprise. In 
addition, diagnostic intelligence added to each asset or a device connected thereto allows 
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the call asset manager to identify failed equipment from a central location. Finally, 
software and firmware updates can be sent to the call center assets from the central 
mmagement computer, either to a single asset or broadcast to a group of assets. 
[0011] The system may also include fimctionaHty for controUing one or more call 
center assets on the network. For example, the central management computer may 
command the handset Ufter to Uft the handset when the ACD routes a call to the 
associated user. Once the call is finished, the central management computer then lowers 
the handset. 
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Brief Description of the Drawings 
[0012] Fig. 1 is a diagram of an embodiment of the call center asset management and 
control system. 

[0013] Figs. 2A-D are diagrams of different embodiments of a generic call center 
asset, and perhaps its proxy device, having different levels of incorporated intelligence. 
[0014] Figs. 3-7 are diagrams of different embodiments of a physical layer interface 
implementation for connecting the call center assets of a station to a central management 
computer. 
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Detailed Description of the Preferred Embodiments 
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A. System Architecture 

[0015] Fig. 1 is a diagram of an embodiment of the call center asset management and 
control system 100. In the system 100, one or more call center assets 105 are coupled to 
a network 1 10, which is further coupled to a management and control computer 1 15. In 
an embodiment, the computer 115 comprises a standard computer system. Some 
"inteUigence," in the form of appropriate hardw^e, software, firmware, or a combination 
thereof, is incorporated into the call center assets 105 for perforaiing management or 
control functions. Altematively, a proxy 120 may be coupled to one or more call center 
assets 105 and the network 1 10. In one embodiment, the proxy 120 provides some or all 
of the management and/or control fimctionality for the call center asset 105 associated 
therewith. In another embodiment, the proxy 120 is used to communicate over the 
network for one or more assets 105 associated therewith. 
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1 . The Call Center Asset 

[0016] A call center asset includes telecommunications devices and systems used in 
a call center, such as a telephone, headset, headset adapter, on-line indicator (OLI), 
handset lifter, or other device for implementing the communication features of a call 
center. In one embodiment, the asset 105, or the combination of the asset 105 and a 
proxy 120, include 'InteUigence," in the form of a processor, program memory, buffer 
memory, and/or software to perform network, management, and/or control operations. 
In addition, a physical layer interface is provided for the call center asset 105 to enable 
connectivity with the management and control computer 115 over the network 110. 
[0017] To facilitate communication over the network 1 10, the call center asset 105 is 
associated with a network address. Messages can be broadcast to a particular address, 
and hence to the call center asset 105 associated therewith, fi-om another device on the 
network 1 10, such as the management and control computer 115, In a preferred 
embodiment, a call center asset 105 has an electronic serial number 125 that is globally 
unique, or mappable to a globally unique address. In other preferred embodiments, a call 
center asset 105 is coupled to a proxy 120, which assigns a network address to the call 
center asset 105. 

[0018] Depending on the application, it may be desirable for each call center asset 
105 to have a globally unique address (meaning that the asset 105 does not have the 
Sdxne address as another device on the network 110). In other circumstances, it may be 
desirable for several call center assets 105 to have the same network address. In the 
latter case, for example, it would be possible to broadcast data to multiple call center 
assets 105 simultaneously. This technique could advantageously be used to transmit 
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software or firmware updates to a group of call center assets 105. In another 
embodiment, a single call center asset 105 may have associated therewith multiple 
network addresses, some or all of which could also be shared among several assets 105. 
In this way, each call center asset 105 could be a "member" of several groups of call 
center assets 105, the members of the group having the same network address. Each 
asset 105 could thus be adapted to receive data broadcasted to each group in which the 
asset 105 is a member. 

[0019] The network addresses may be determined from the call center assets 105 or 
from m associated proxy 120. In one embodiment, a call center asset 105 includes an 
electronic serial number 125, from which one or more network addresses can be 
determined. In another embodiment, a proxy 120 associated with the asset 105 includes 
an electronic serial number 125, from which one or more network addresses for the 
associated call center asset 105 are determined. 

[0020] Figs. 2A through 2D show several embodiments of a call center asset 105 
having varying degrees of intelhgence incorporated therein, generally decreasing from 
Fig. 2A to 2D. In Fig. 2A, the call center asset includes a globally unique electronic 
serial number 125, which is used to identify the asset 105 on the network 1 10. In one 
embodiment, the electronic serial number 125 is the asset's Media Access Control 
(MAC) address (described below); however, the electronic serial number 125 maybe 
any number that is mappable to a network address. 

[0021] The asset's electronic serial number 125 is available to a network interface 
210. The network interface 210 is adapted to derive a network address for the asset 105 
using the asset's electronic serial number 125. In a preferred embodiment, the network 
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address derived from the electronic serial number 125 is unique on the network 110; 
however, in some implementations it may be desired that two or more call center assets 
share a network address. For example, the network interface 210 may be configured to 
create a network address based on the type of call center asset. Additionally, the 
network interface 210 may create multiple network addresses — for example, one 
unique network address for diagnostic and tracking purposes and another shared address 
for receiving broadcasts such as software updates and system-wide commands. 
[0022] The network mterface 2 1 0 is adapted to communicate over the network 1 1 0 
using the network address that it derives for the asset 105. In one embodiment, the 
network interface 210 communicates over the network 110 using the Internet protocol 
(IP), wherein the network interface 210 uses the asset's MAC address or another globally 
xmique address as its IP address. However, the network interface 210 may communicate 
using any of various protocols known in the art. For example, firaiware updates may be 
sent to each individual device using unicast addresses, using for example the File 
Transfer Protocol (FTP), Transfer Control Protocol (TCP), or User Datagram Protocol 
(UDP). In other embodiments, firmware updates are sent to an entire collection of 
identical devices simultaneously by setting up a single multicast address on each of them 
and then broadcasting the software updates to all of the devices simultaneously. This 
method typically uses UDP and preferably ensures that all of the devices successfully 
received the entire update. 

[0023] The call center asset 105 further includes a management module 220 and a 
control module 230, each coupled to the network interface 210. The central 
management computer 1 15 sends and receives communications to the management 
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module 220 and control module 230 to implement the system's management or control 
functions (described below). The network interface 210 receives these communications 
from the central management computer 115 and routes them to the management module 
220 and/or control module 230 as required. The network interface 210 also sends 
communications from the management module 220 and control module 230. The 
management module 220 is adapted to perform the management functions of the system, 
as described below, including tracking asset utihzation and location, performing system 
diagnostics, and receiving software or firmware updates. The control module 230 is 
adapted to perform the control functions required by the system, as described below. 
[0024] Fig. 2B is an embodiment of a call center asset 105 that uses a proxy device 
120. hi this embodiment, the proxy device 120 mcludes a network interface 210 for 
sending and receiving messages over the network 1 10. The network interface 210 may 
have access to an electronic serial number 125, as described above, for determining the 
asset's network address. The electronic serial number 125 may be on the proxy device 
120 (as shown) or on the asset 105 itself. Alternatively, the network interface 210 may 
be adapted to determine a network address for the asset 105 without using an electronic 
serial number 125. For example, the network interface 210 may assign the asset's 
network address dynamically, after polling the network, or requesting an address from 
the central management computer 1 15. In this embodiment, the call center asset 105 
includes the management module 220 and the control module 230 for performing the 
system functions, both of which communicate with the network interface 210 for 
sending and receiving messages from the central management computer 115, 
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[0025] In the embodiment of Fig. 2C, the call center asset includes the network 
interface 210 and electronic serial number 125, as described, but uses a proxy device 120 
for implementing the management and control functions. This embodiment may be 
useful to implement added management or control functions on existing call center 
assets that already include network capability. Accordingly, in m embodiment, both the 
call center asset 105 and the proxy device 120 may include a management module 220 
and a control module 230, Proxies may thus be added to upgrade the fimctionaUty of the 
call center assets and the management and control system. 

[0026] The embodiment of Fig. 2D depicts a "dumb" call center asset 105, which 
incorporates little or no intelligence for network capability or system functions. A proxy 
device 120, coupled to the asset 105, performs the management and control functions 
and communicates with the central management computer 1 15 for the asset 105. In one 
embodiment, the call center administrator sets up a pool of globally unique addresses 
allocated to the call center, either by the IEEE Registration Authority or from a network 
address server pool. Then, an asset is assigned one of these addresses, and the proxy that 
manages that asset is configured to recognize that address and associate it with 
management commands sent to that address. 

[0027] These various embodiments for implementing inteUigence in connection with 
a call center asset demonstrate the versatility of the system. New call center assets can 
be added to an existing system and can perform all of the functions required without 
additional hardware. In addition, existing legacy equipment, having little or no 
intelligence, can be used with the system by employing a proxy device (as shown in the 
embodiments of Figs. 2A-D). Furthermore, the system can be upgraded by using proxy 
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devices to implement additional system functions, without requiring a complete overhaul 
of an enterprise's call center assets. 

2. Addressing a Call Center Asset on the Network 

[0028] As discussed above, in one embodiment the network address of a call center 
asset 105 is determined from an electronic serial number 125. For example, in an 
embodiment of the network using the Ethemet protocol, an asset's network address can 
be determined from its Media Access Control (MAC) address. 

[0029] The Ethemet packet prefix consists of a preamble, a start code, a destination 
address, a source address, and the packet length field, followed by the packet payload 
and a CRC field. The source and destination addresses are each 48-bit values, known as 
MAC addresses, or "MAC-48" addresses. The Institute of Electrical and Electronic 
Engineers (IEEE) also refers to the MAC address as an "EUI-48" identifier. The MAC- 
48 address is composed of a 24-bit "Organizationally Unique Identifier" (OUI) and a 24- 
bit extension field: 

MAC-48 = [OUI(o through 23)] I [extension(o through 23)]. 
The OUI is a unique value that identifies the company or organization that manufactured 
the particular Ethemet interface. These OUI values are assigned and administered by the 
IEEE registration authority. For example, the OUI Usted for Plantronics, Inc. in the 
lEEE/RA database is 00-03-89 (hexadecimal). 

[0030] The extension field is a 24-bit value that can be assigned in any way the 
organization listed in the OUI field may choose. Under the IEEE standards, the 
organization is to ensure that each physical interface has a unique number; therefore, 
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there will never be two interfaces that have the same combination of OUI and extension. 
This ensures a device's MAC -48 address will be a globally unique identifier, as there 
will never be another device anywhere in the world that has the same MAC-48 address. 
Advantageously, this globally unique identifier can serve as an electronic serial number 
for every device that a company manufactures, either directly or via a mapping scheme 
that is mathematically "one-to-one" and "onto " Using the MAC-48 address with a 24- 
bit extension field, an organization can manufacture up to 16,777,216 (2^"*) physical 
devices having globally unique MAC addresses. 

[0031] However, some larger companies are approaching this limit of shipped 
products with an Ethemet or other form of interface, which requires a globally unique 
identifier. (IEEE-1394 "Firewire" also uses the MAC-48 address as a globally unique 
identifier.) Therefore, these organizations require some way to expand beyond the 16- 
million device limit. There are two possibiUties. 

[0032] The first approach is to assign multiple OUIs to each organization that 
fabricates more than 16 miUion devices. From the IEEE Registration Authority's 
database, around 5,000 OUIs have already been assigned to various organizations, 
including the one for Plantronics, Inc. mentioned above. Since the OUI field is also 24 
bits, there are also 16,777,216 possible OUIs, of which about 16,772,000 are still 
available. Organizations that produce more than 16-miUion devices may obtain an 
additional OUI, but this is a short-term solution. Any organization that has fabricated 16 
million interface devices within the last 30 years is likely to use up a second allocation of 
16 milUon MAC-48 addresses much quicker. Also, softw^e designed to automatically 
manage all devices within an organization would have to be completely rewritten every 



Case 6267 



-14- 



1 8864/06267/SF/50642 18.1 



time a new OUI is assigned to that organization, and all of the previous software 
presently operating in the legacy equipment would be incapable of recognizing devices 
with the new OUI. 

[0033] Another embodiment uses a globally unique identifier that provides a larger 
extension field, such as the IEEE MAC-64 identifier, more recently referred to by the 
IEEE as the EUI-64, The EUI-64 is a 64-bit value consisting of two fields: the 24-bit 
OUI as described previously and a 40-bit extension field. This 40-bit extension field is 
large enough to accommodate up to 1,099,51 1,627,776 (2"^^) different electronic serial 
numbers, which is expected to be several orders of magnitude greater than any single 
organization will ever need. It is noted: 

EUI-48 = MAC-48 = [OUI(o through 23)] 1 [extension(o through 23)], 

whereas 

EUI-64 = [OUI(o through 23)] I [extension{o through 39)]. 
However, EUI-64 identifiers are appropriate for IPv6 hitemet protocols, as opposed to 
the more common IPv4 Internet protocols, which normally use EUI-48 identifiers. IPv6 
is still in the process of being implemented through out the Internet backbone, but should 
be ubiquitous within the next few years. 

[0034] A system in accordance with the present invention can be implemented 
initially using EUI-48 identifiers mapped to IPv4 Internet protocols and then generaUzed 
at a later time to EUI-64 identifiers using IPv6 protocols. With time, the Pv6 protocols 
should be more common on the Internet and the cost increment for an IPv6 protocol 
stack over the IPv4 stack on any product should decrease to the point that it becomes 
acceptable to switch over to IPv6. 
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[0035] In one embodiment, each call center asset is shipped from the manufacturer 
with its own electronic serial number, which is mappable to a globally unique network 
address such as an IP address. The asset may then be accessed from anywhere on a 
network, such as the Internet, via this address. However, many organizations prefer to 
assign IP addresses to all devices attached to their network from within their own 
assigned range of IP addresses. If a device supports the Dynamic Host Configuration 
Protocol (DHCP), then it can accept commands to assign it additional IP addresses. 
During what is referred to as the "discovery process," devices supporting DHCP 
announce their presence on the network at the time they are connected (either tumed on 
or plugged in) and then a DHCP server assigns a "dynamic IP address" to this device 
from within the address range assigned to the organization. This is usefiil for "campus 
wide" asset management, in which broadcasts are sent to several assets. 
[0036] The DHCP server may also assign the device a "group address," that all of 
the devices of a p^cul^ type can share. In this case all of the devices assigned that 
same group address can accept data packets sent to that group address. This is useful for 
"broadcasting" information to multiple devices at the same time. This is often used for 
streaming multimedia information to multiple users simultaneously. In a call center, for 
example, this could be used for broadcasting announcements to all of the telephones 
simultaneously. It can also be used for distributing software or firmware (software that 
is stored in non- volatile re-writable memory) upgrades to all of the devices at once. This 
capability is usefiil in a call center when the administrator wishes to upgrade the 
firmware in all of the assets of a particular type (e.g., all headsets) at once. 
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[0037] In another aspect of an embodiment, Intemet Protocols (IP) and unique 
Media Access Layer (MAC) addresses, as used on Ethernet networks, are used to 
facilitate communications among the call center assets 105. Advantageously, using IP 
and MAC addresses provides physical layer independence. Physical layer independence 
means that the call center assets 105 can be coupled to a management and control 
computer 115 (and thus to the Intemet) via a wide variety of data interconnect standards, 
including Ethemet (IEEE-802, including all variations), Token Ring, EIA-232, EIA-422, 
EIA-485, Universal Serial Bus (USB), IEEE-1394, BLUETOOTH®, and 
modulator/demodulator (modem) signaling over the telephone circuit (using either in- 
band signaling where the data uses the same signal path as the audio or out-of-band 
signaling where the data uses separate signal wires). The in-band signaling can also be 
used during a telephone conversation by using the data signaling to modulate carrier 
frequencies either below or above the range of human hearing, such as the approach used 
for conveying DSL service over a telephone local loop. 

[0038] The Intemet Protocol requires a unique Intemet address. This address may be 
preset and static, or it can be dynamic, whereupon a central registration server assigns 
the address whenever a new device announces its presence on the network. Ethemet 
networks operate by use of a unique network address at the Media Access Control 
(MAC) layer, called the MAC address, which may or may not be related to the ff 
address. A typical implementation keeps the IP and MAC addresses independent for 
flexibility. The MAC address is usually a fixed value, established as a unique number at 
the time the network interface device is manufactured. As such, the MAC address can 
also be used as an electronic serial number for the device containing the network 
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interface, either directly or via some translation algorithm that provides a one-to-one 
mapping. The MAC address should be unalterable, implemented by, e.g., a one-time 
programmable read-only memory, circuit board jumpers, or another similar mechanism. 
[0039] The definitions of the MAC address and the IP address have addressing 
capability that permits call center implementations having biUions of units. This 
functionality greatly increases the scalabihty of the call center asset management and 
control system. The Latemet Protocol also permits the use of bridges, gateways, and the 
like to provide for the global interconnection of bilhons of units in widely separate 
locations into one worldwide connection, such as the Internet itself. 
[0040] Because the Internet Engineering Task Force (IETF) documents the standards 
that comprise the Internet Protocol, these standards are well known and widely available. 
Furthermore, the popularity of the Internet ensures that many solutions from various 
vendors are available at varying prices and levels of performance. 
[0041] The electronic serial number in each call center asset (or its proxy) can be 
used for asset tracking, which allows a call center manager to track call center assets that 
have been moved within the call center and to identify assets that are missing or 
defective. Moreover, the Intemet Protocol can be used to convey commands from a 
management computer to provide any management fimctions, such as detecting whether 
a telephone is in use or other aspects of its state. The utilization of call center assets can 
thus be ascertained. The Intemet Protocol can also be used to convey commands from a 
central management computer 1 15 to a call center asset for performing diagnostics. By 
combining these techniques using standard Intemet programming software tools, custom 
applications can be produced to generate automated software packages for asset tracking, 
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station utilization, and xrnit diagnostics. Furthermore, these functions can be performed 
by a call center manager or by another system coupled to the network. For example, the 
manufacturer of a particular call center asset, in addition to the call center manager, 
could diagnose the failure of the call center asset by communicating with it over the 
Internet. 

[0042] In addition, as the equipment manufacturer improves the software or 
firmware that operates within a call center asset, the new version of the software or 
firmware could be made available to existing customers by transmitting it over the 
network to the relevant call center assets. For example, call center managers could 
update the software or firmware by downloading the latest version from the 
manufacturer's web or ftp site and then transmitting the new version to the relevant call 
center assets according to the desired upgrade schedule. Altematively, the equipment 
manufacturer could perform the upgrade to the call center assets remotely over the 
network by transmitting the upgrades directly to the call center assets. This might be 
facilitated by manual or automatic coordination between the manufacturer and the 
manager to avoid updating a piece of equipment while it is in use. 

3. Full Ethernet Connectivity Call Station Embodiment 
[0043] Fig. 3 illustrates one embodiment of a call center station 300. In this 
embodiment, connectivity is implemented by using Ethernet interfaces (e.g., IEEE-802, 
all types) to every call center asset in the station, as well as to either a station computer 
305 located in the station or to a central call center computer. The call center assets 
accommodated in this embodiment include a headset 310, a headset adapter 315, an on- 
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line indicator (OLI) 320, a handset lifter 325, and a telephone 330; however, any suitable 
telecommunications device could be used with the system. Each of the call center assets 
(the telephone 330 if Ethernet-enabled) and the station computer 305 are coupled to an 
Ethernet hub 330, which is coupled to the central management computer 115. The call 
center station 300 may have its own Ethemet hub 330, or it may share a hub 330 with 
other stations. Because Ethemet is relatively expensive, this embodiment is relatively 
expensive to implement. 

[0044] Li addition, if call center connectivity to the Internet 340 is provided, 
additional security mechanisms, such as an Internet firewall 345, are preferably provided 
as well. Mtemet connectivity is commonly required for many call centers, hi an 
embodiment, the central management computer 115 is communicatively coupled to a 
customer service computer 350 over the hitemet 340. The customer service computer 
may be maintained by, for example, the manufacturer of one or more of the call center 
assets. Accordingly, the customer service computer 350 may supplement the call center 
management and control functions of the central management computer 115, which is 
typically operated by an enterprise. For example, the manufacturer of a particular call 
center asset could provide automatic software or firmware updates to each of an 
enterprise's call center assets using the customer service computer 350; thus, the call 
center administrator would not have to download the update from the manufacturer and 
perform the updates manually via the central management computer 115. Additionally, 
a manufacturer could retrieve data regarding utihzation and diagnostics of the call center 
assets produced by the manufacturer, without having to retrieve this data from the 
enterprise. 
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4. Cost Effective Call Station Embodiment 

[0045] Figs. 4A and B illustrate more cost effective embodiments than shown in Fig. 
3. In these embodiments, a bi-directional, multi-drop connection is provided between 
the station desktop computer 305 and the other call center assets in the station, including 
some or all of: the telephone 330, the headset 310, the headset adaptor 315, the OLI 320, 
and the handset Hfter 325. Examples of suitable interconnections include Universal 
Serial Bus (USB) and the Plantronics Serial Bus (PSB). The PSB is described m 
"Accessory Interface Bus." In the embodiment of Fig. 4A, a USB/PSB interface 355 is 
coupled between any call center assets that use the PSB format and the station computer 
305 (which has a USB port). Li the embodiment of Fig. 4B, the headset adapted 315 
incorporates the USB to PSB interface functionality. The station computer 305 is 
configured with an Ethernet interface and is used as a gateway between the call center 
assets and the central management computer 115, and possibly to the Internet 340. 
[0046] The USB to PSB interface 355 can be a separate device, as shown in Fig. 4A, 
or it can be incorporated into the headset adapter, as shown in Fig. 4B. Altematively, the 
USB interface may be routed to all of the connected devices. The choice of network 
media is an economic decision that is driven by the relative cost of implementation and 
does not materially affect the substance of the invention, 

[0047] This cost effective solution provides an upgrade path for existing call centers 
having a large investment in legacy equipment. By providing an interface between the 
station desktop computer 305 and the control bus used by the existing equipment, the 
desktop computer 305 operates as a network proxy for the other instruments in the 
station, translating Internet Protocols to the native protocols of the legacy equipment 
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control bus. However, because the existing legacy instruments may not provide a unique 

electronic serial number, the proxy may have to simulate one or otherwise determine a 
network address for its associated asset. 



5. Audio Signaling Call Station Embodiment 

[0048] In the embodiment of Fig. 5, an interface is provided that multiplexes the data 
signaling into the telephone audio path itself The telephones 330 of each call center 
station 300 are coupled to the central management computer 1 15 by a private brmich 
exchange (PBX) 365. The PBX 365 switches calls within an enterprise between stations 
300 on private hnes while allowing the stations 300 to share a number of public 
telephone hnes. The central management computer 115 modulates data packets to the 
call stations 300 using a modem 360, implemented either separately or via software 
operating on the same processor used to interpret the Internet Protocol packets. 
[0049] The data packets can be implemented "in band" (within the telephony audio 
frequency range), "out of band" (outside the telephony audio frequency range), or both. 
In the embodiment where the signaling is performed "in-band," the headset adapter 315 
senses the existence of modem signahng on the audio line, mutes the audio, and 
demodulates the incoming data packet. In this case, the management and control 
functionality can only be implemented when the telephone 330 is not in use. In the "out 
of band" signaling embodiment, data communications are allowed while the telephone is 
in use. This approach is used in Digital Subscriber Line (DSL) modems, as described in 
ITU-T Recommendation G.991.2, "High bit rate Digital Subscriber Line (HDSL) 
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transceivers." A DSL modem, either as a separate piece of equipment or incorporated 

into the telephone, can be used for this apphcation. 

[0050] This embodiment permits both corded and cordless headsets to be managed 
using equipment that is backwards compatible with existing legacy equipment, hi the 
cordless case, many wireless headset technologies, such as BLUETOOTH® and DECT, 
use digital radio links between the base and the headset. These digital radio systems 
usually provide an altemate path for the transmission of digital data between the base 
and the headset. Therefore, even though the telephone link may be used for the IP-based 
data communications with a remote device over the Intemet, the local IP-based data 
communications between the headset adapter and the wireless headset typically uses a 
parallel digital chamiel, not the audio chaimel. This keeps the modem function in the 
headset adapter, rather than requiring a modem function in the headset itself. In one 
embodiment, the modem function is incorporated into the headset adapter 315, or 
altematively the headset 310. In the latter case, the headset 310 would be a manageable 
device without affecting its plug-in compatibility with the existing call center equipment. 
[0051] While many call centers have a computer system in each station to run 
customer management software for the agent's convenience, this embodiment does not 
requne one. This avoids the additional cost of a computer system located in each call 
center station. Also, in some instances, call center managers may not wish to provide 
each station with a computer. Advantageously, the asset management and control does 
not depend on the proper operation of the station computer, which increases the 
rehability of the system. 
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6. VoIP Signaling Call Station Embodiment 

[0052] Figs. 6A and B show other embodiments, wherein a headset adapter 3 15 is 
coupled to a Voice over IP (VoIP) telephone 370. Examples of conmiercially available 
VoIP telephones include models 2002, 2004, 2050 from Nortel Networks, Inc.; model 
4612 from Avaya Inc.; and model 7960 from Cisco Systems, Inc. Here, the VoIP 
telephone 370 serves as a gateway, as per ITU-T Recommendation H.323, to the central 
m^agement computer 1 15. In Fig. 6 A, the call center assets are implemented directly 
as IP devices (such as ITU-T Recommendation H.323 terminals) and are connected to 
the VoIP telephone 370 directly or via the headset adapter 315. 
[0053] In Fig. 6B, the headset adapter 315 serves as a gateway for the other call 
center assets. In an embodiment, the headset adapter 315 includes a network interface of 
any type, including but not limited to: IEEE 802.3 CSMA/CD, IEEE 802.4 Token bus, 
IEEE 802.5 Token ring, IEEE 802.1 1 Wireless Local Area Network (WLAN), IEEE 
802.15 Wireless Personal Area Network (WPAN), and IEEE 802.16 Broadband wireless 
access. These other call center assets, including the headset 310, OLI 320, and handset 
lifter 325, conununicate with the headset adapter 315 using an interconnection such as 
USB or PSB. Because the call center assets do not communicate through the telephone 
370, this embodiment is also compatible with an analog telephone station. 

7. Other physical layer interface embodiments 

[0054] Fig. 7 shows yet another embodiment, wherein the headset adapter 315 serves 
as a gateway for the other call center assets to the central management computer 115. 
The headset adapter 315 is also coupled to a telephone 330, which communicates with a 
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public telephone system 375 via a PBX 365. In this embodiment, the voice and data 
paths to are split at the headset adapter 315, 

[0055] In other embodiments, the headset adapter serves as a proxy, translating IP 
packets into any proprietary protocol known by the accessories (similar to the address 
translation services provided by an ITU-T Recommendation H.323 compliant gateway 
function). 

[0056] Call center assets that provide a imique electronic serial number can be 
tracked according to either (1) a directly mapped IP address; (2) via an IP address 
mapped by the headset adapter; or (3) the VoIP telephone, acting as m IP proxy. The IP 
proxy can manage conmiunications to accessories that do not have a unique electronic 
serial number by simulating appropriate numbers, but the asset management and control 
functionality of those accessories would be complicated by the need to manage the 
proxy's simulated serial numbers. 

[0057] The IP control traffic for any of the call center assets can be implemented 
either as VoIP data, such as an ITU-T Recommendation T.120 data packet, or as a 
separate IP data stream. This is the functional equivalent of in-band signaling and out- 
of-band signaling for VoIP apphcations. 

[0058] Similar implementations are possible via ISDN or similar switched circuit 
telephony equipment. The appropriate mapping of the IP packets onto the switched 
circuit interface is required. Such mappings are defined by intemational telephony 
standards. 
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B. Applications to Asset Management and Control 

[0059] Accordingly, call center and office telephony assets, such as the embodiments 
described in connection with Fig. 2A through D, can be managed and controlled over a 
network by a remote system, as shown in Fig. 1 , Depending on the design specifications 
and system requirements, any of a number of methods for coupling the assets to the 
network can be used. Figs. 3 through 7 illustrate several embodiments of a physical 
layer mterface for connecting call center assets to a central management computer. Once 
a central management computer is provided with connectivity to a number of assets 
having suitable intelligence, an operator using the computer can perform various tasks 
regarding the management and control of these assets, hnportantly, the network gives 
the operator a great deal of flexibility to manage and control the assets from any number 
of physical locations, and it enables the operator to manage and control assets at a 
nvmaber of different locations. 

[0060] To effect asset management, an asset*s management module 220 preferably 
uses a high-end protocol that is known to the network interface 210 and the computer 
115. Likewise, to effect asset control capabilities, the control module 230 uses a high- 
end protocol that is known to the network interface 210 and the computer 1 15. An 
example of a suitable protocol for communicating with call center and office telephony 
assets is described in "Accessory Literface Bus." This protocol defines a command set 
and associated response packets for managing and controlling one or more assets; 
however, this command set may be expanded or modified depending on the assets 
supported and desired functionality. 
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1 . Asset Management: Asset Utilization 

[0061] In one embodiment, the central management computer 115 monitors the 
utilization of one or more assets 105 over the network. An asset's utilization may 
include whether the asset is in use, the type of use, or its use history. For example, the 
utilization for a telephone may be defined as whether there is an active call on each of 
the telephone's lines, and whether each active call is on hold. The utihzation of a 
headset or headset adapter may be defined as whether the asset is currently carrying a 
call. 

[0062] hi an embodiment, the asset 105 includes a management module 220 
programmed to detect and report on the asset's utilization. Responsive to a request firom 
the network interface 210, the management module 220 sends the network interface 210 
a signal indicating the asset's utihzation. At predetermined intervals or responsive to 
specific requests firom the central management computer, the network module 210 sends 
data relating to the asset's utihzation to the central management computer. The central 
management computer may query the assets on a daily, weekly, or monthly basis. 
[0063] In another embodiment, the asset's management module 220 includes 
software for logging utilization statistics. At predetermined intervals or responsive to 
specific requests firom the central management computer, the network module 210 sends 
this logged data to the central management computer. After the data are transmitted, the 
management module 220 preferably clears the data from memory for storing additional 
utihzation data. 
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[0064] In another embodiment where a headset supports JP functions, the PBX or 
VoIP router detects when a user disconnects the headset from the system. The system 
detects the disconnection, e.g., by periodically polling the headsets and receiving replies. 
If no reply is received, the system assumes the headset has been disconnected. The ACD 
is then notified of the disconnection, allowing the ACD to avoid routing future calls to 
the associated station. When a user reconnects a headset, the system detects that the 
headset is connected, e.g., because the headset replies to periodic polls. The system 
notifies that the headset is connected, and the ACD may thereafter resume routing 
telephone calls to that station. 

2. Asset Management: Asset Location 

[0065] The system also enables an operator to identify the specific location of a 
particular managed asset using the network. In one embodiment, the central 
m£uiagement computer uses the asset's IP address to locate it. In an embodiment, the 
central management computer sends an echo message, as per the Intemet Control 
Message Protocol (ICMP), defined in IETF RFC 792, with the ICMP-defined "Time To 
Live" field set to "1." This limits the number of network hops to a single hop, causing 
the first intermediate device in the path to answer the echo message back to the central 
management computer with its address. The central management computer then repeats 
the echo message to the asset's IP address with the "Time To Live" field set to "2," 
which causes the second node device to respond to the echo message with its address. 
This process is repeated, incrementing the "Time to Live" field each time until either the 
address of interest is reached or until some predefined limit is reached. If the predefined 
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limit is reached before finding the desired asset's address, it is assumed that the asset is 
not available on the network. Once the asset's IP address has been reached, the echoed 
addresses of the repeated echo repUes provide a linear map of the path to the desired 
asset, which can be used to infer the device's physical location by knowing, a priori, the 
connection topology of all of the assets and the nodes to which they attach. The 
intermediate devices, specifically Litemet routers, may be network assets under the 
control of the network administrator, or they may be part of a larger network, such as the 
backbone routers to the Intemet itself 

[0066] When the management computer receives the echoed message, the computer 
searches through the Ust of inteimediate devices, comparing it against the database of all 
of the network devices under its management. By knowing the location of the 
intermediate devices and mapping the path of the message according to the physical 
locations of the devices, the central management computer has determined the location 
of the asset. 

3. Asset Management: Diagnostics 

[0067] Using the central management computer, an operator can also perform 
various diagnostic tests over the network to verify the proper operation of a specific 
asset. Diagnostic tests may be performed periodically via a preprogrammed automatic 
fimction within the management computer, or they may be performed manually 
responsive to commands of a human operator using the central management computer. 
In addition, a group of assets (e.g., all headsets) can be tested simultaneously by 
broadcasting diagnostic commands to the group of assets. 
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[0068] la one embodiment, the management computer sends a diagnostic command 
over the network to an asset using the asset's network address. The network module 210 
of the asset having that network address receives the diagnostic command, and forwards 
the command to the management module 220. Responsive to this command, the 
management module 220 performs the requested diagnostic operation. Typically, the 
diagnostic command is specific to the type of asset (e.g., headsets), and any of a vmety 
of diagnostic operations can be performed. 

[0069] After performing the diagnostic test, the management module 220 passes the 
result of the test to the network module 210, which sends the result over the network to 
the central management computer. The result may be, e.g., an indication that the 
diagnostic operation passed or failed. If the diagnostic operation failed, the result may 
also include some ^ciliary information regarding the nature of the failure. This 
ancillary information may be in the form of human-readable descriptive text or an error 
code, which the management computer checks against a database of error codes 
explaining the failure and what corrective action should be taken. The management 
computer preferably initiates the corrective action automatically or signals a request for 
corrective action to an operator. If the central management computer does not receive a 
reply within a predetermined timeout period, it is assumed that the asset has failed or 
that there is a network failure. 

4. Asset Management: Software or Firmware Updates 

[0070] The system also enables the central management computer to perform 
software or firmware updates over the network for a specific asset or a set of assets of 
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like type (e.g., all headset adapters). In one embodiment, the central management 
computer distributes the updates to each asset within its management domain one device 
at a time, e.g., using File Transfer Protocol (FTP), Transport Control Protocol (TCP), or 
User Datagram Protocol (UDP). 

[0071] In another embodiment, the central management computer distributes the 
update to all assets of like type by previously setting up a multicast network address and 
associating each device with this multicast network address. In an embodiment, the 
software or firmware update is sent to the multicast network address, to which a set of 
assets responds. The network module 210 associated with each asset in the set is 
adapted to save the software or firmware update payload into a reserved part of memory. 
[0072] After the update is saved in the memory, the management computer 
commands the assets to reinitialize using the new software or firmware, broadcasting 
this command to the same multicast network address or to each asset individually. Once 
this is accomplished, the management computer preferably verifies the proper update 
software or firmware by querying each asset's software or firmware version number. If 
an asset does not reply with the new version number, the management computer 
preferably attempts to update the software or firmware again, addressing only those 
assets that were not updated. Preferably, if the management computer fails to update the 
software or firmware of a particular asset a given maximum number of times, an error 
message is forwarded to the operator and the management computer stops trying to 
update asset. 
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5. Asset Control 

[0073] In addition to asset management, the system enables the active control of 
assets coupled to the central management computer via the network. In one 
embodiment, when the ACD routes a call to an individual telephone in a call station, the 
system sends commands to the station's handset lifter to Uft the handset. In another 
embodiment, the ACD sends commands to the on-line indicator (OLI) associated with 
that telephone to indicate that the user is presently engaged in a telephone conversation. 
For example, the system may send a command to change the Ughting pattern of the OLI 
to indicate the appropriate status of the call. 

C. Protocol Layers on the Internet 

[0074] The definition of the Intemet consists of a set of protocol layers, roughly 
following the ISO seven-layer Open Systems Interconnect (OSI) Reference Model 
(OSI/RM), as per ISO/IEC 7498-1 : 1994. The layers of interest in this discussion are as 
follows: 



OSI Layer 


Protocol 


Standard 


1 


Physical Layer 


10/lOOBaseT 


IEEE 802.3 


2 


Data Link Layer 


CSMA/CD & LLC 


IEEE 802.3 & IEEE 802.2 


3 


Network Layer 


IPv4, IPv6 


IETFRFC791,RFC2460 


4 


Transport Layer 


UDP, TCP, FTP 


IETF RFC768, RFC793, RFC959 


5 


Session Layer 


RTP 


IETFRFC1889, RFC1890 


6 


Presentation Layer 


VoIP 


ITU-T Rec. H.323 
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[0075] At the Physical Layer, the most common intercomiect used for Intemet 
communications is the Ethernet standard, using either lOBaseT (10 Mbps signaling) or 
100BaseT (100 Mbps), as per IEEE 802.3. Indeed, a standard cable modem or DSL 
modem used for Intemet access connects to the computer via either a lOBaseT or 
100BaseT interface. These interfaces use the ubiquitous RJ-45 connector with twisted 
pair cable. A new version of the Ethemet standard is available that supports 1,000 
Mbps, and there are plans for a 10,000 Mbps version. Similarly, wireless versions, as 
per IEEE 802.11, IEEE 802.15, and IEEE 802.16, are either available or planned. 
[0076] At the Data Link Layer, the Ethemet standard uses Carrier Sense Multiple 
Access with CoUision Detect (CSMA/CD), as per IEEE 802.3. With CSMA/CD, when 
an interface wishes to trausmit a packet, it Kstens on the network to see if something else 
is transmitting (Carrier Sense). When it detects that the network is quiet, it begins to 
transmit the packet. To guard against two devices' beginning to transmit at the same 
time, the interface listens to the network while it is transmitting. If the interface detects 
an interfering signal on the network, it stops the transmission and waits a random 
number of milliseconds before attempting to retransmit (ColUsion Detect). A variation, 
called CSMA/CA (CoUision Avoidance), is used for wireless networks, as described in 
IEEE 802.11. 

[0077] At the Network Layer, the Intemet Protocols provide the packet addressing 
and routing information to ensure that the packet can reach the destination through the 
Intemet. There are two versions of the Intemet Protocol, known as IPv4 and IPv6, for 
version 4 and version 6 respectively. The main difference between these two versions is 
the Intemet address space. IPv4 uses 32-bit addresses, and IPv6 uses 128-bit addresses; 
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therefore, the IPv4 address space is a subset of the much larger IPv6 address space. The 
change from IPv4 to IPv6 was required because every device in the Internet requires a 
unique IP address, and the explosion in popularity of the Internet would exhaust the 
supply of available 32-bit addresses. 

[0078] At the Transport Layer, the control stream may use either UDP datagrams or 
TCP connections. User Datagram Protocol (UDP) is a one-way protocol, sending 
"datagrams" in one direction. The protocol itself does not maintain any form of 
connectivity with the destination device, nor does it necessarily expect any kind of 
response from the destination device. Transmission Control Protocol (TCP) estabUshes 
a virtual "connection" over the Intemet with the destination device. TCP maintains this 
connection by occasionally polling whether the other device is still available. TCP also 
expects a reply for every packet it sends to the destination device, which serves as a 
confirmation of receipt. If such a reply is not received within a certain amount of time, 
the packet is resent. 

[0079] For VoIP appUcations, there are several separate data streams: the video and 
audio data streams and the control streams. IP control of assets in a call center that uses 
analog telephones only requires the control stream. 

[0080] VoIP applications normally use UDP datagrams for the video and audio 
streams because they require less processing overhead and because the delays involved 
in retransmitting a lost packet, as with TCP, are too long for two-way telephony 
applications. If a UDP packet is lost, then the receive device recovers the best it can, 
perhaps invoking some type of best guess image or acoustic reconstruction strategy. 



Case 6267 



-34- 



18864/06267/SF/5064218.1 



[0081] At the Session Layer, VoIP applications normally use the Real-Time Protocol 
(RTP) for the delivery of the video and audio information. RTP is based on UDP 
datagrams for the reasons mentioned above. 

[0082] A variant of the protocols at the Network Layer, Transport Layer, and Session 
Layer is the Robust Header Compression (RHC) method, described in BETF RFC 3095. 
In this variant, the IP, UDP, and RTP protocol headers are combined and compressed to 
reduce the header overhead to the data packets used to convey the audio telephony 
information. 

[0083] At the Presentation Layer, the VoIP protocols specified in ITU-T 
Recommendation H.323 are used to encode and decode the video and audio signals 
associated with the session. 

[0084] The foregoing description of the embodiments of the invention has been 
presented for the purposes of illustration and description. It is not intended to be 
exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the 
relevant art can appreciate that many modifications and variations are possible in light of 
the above teaching. It is therefore intended that the scope of the invention be limited not 
by this detailed description, but rather by the claims appended hereto. 
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